Allow all the Bitswap CIDs (v1) to pass regardless of used hash#482
Allow all the Bitswap CIDs (v1) to pass regardless of used hash#482dmitry-markin merged 17 commits intomasterfrom
Conversation
|
basically I came to this, when I was debugging and so the empty CIDs here: And the reason was, that they were just filtered out, because of sha2 :) |
| 1 => WantType::Have, | ||
| _ => return None, | ||
| _ => { | ||
| tracing::warn!( |
There was a problem hiding this comment.
nit: Since these warnings can be quite easily user-generated, and not necesarily something we support for our bitswap logic, I would downgrade them to debug to avoid poluting the logs
| if code != u64::from(Code::Blake2b256) | ||
| && code != u64::from(Code::Sha2_256) | ||
| && code != u64::from(Code::Keccak256) |
There was a problem hiding this comment.
Would it be better to extend this functionality and make it configurable via bitswap::Config?
Then, we can add a group of supported hash codes:
// In config:
Config {
...
supported_hash_codes: HashSet<u64>,
}
impl Default for Config {
supported_hash_codes: [u64::from(Code::Blake2b256)].iter().collect(),
}
/// Builder to set supported hash codes for bitswap requests.
///
/// Defaults to supporting only `Code::Blake2b256`.
fn with_supported_hash_codes(&self, codes: impl Iter<Item = Code>) {
self.supported_hash_codes.extend(codes.map(u64::from));
}
// In bitswap:
if self.supported_hash_codes.contains(..)There was a problem hiding this comment.
Would it be better to extend this functionality and make it configurable via
bitswap::Config?
@lexnv Yes, yes, that would be much better. And where do I set those hard-coded values then?
Here?
https://github.com/paritytech/polkadot-sdk/blob/e588acf5e12b14c68331d2e08afe7c12d6671df9/substrate/client/network/src/litep2p/shim/bitswap.rs#L47
let (config, handle) = Config::new()
.with_supported_hash_codes(blake)
.with_supported_hash_codes(sha2)
.with_supported_hash_codes(keccak)
.build();
There was a problem hiding this comment.
Thanks for the suggestions, folks!
I implemented what you suggested but with one minor details:
default_hash_codesare blake, sha2 and Keccak256 -- to maintain backward compatibility with the present code
@lexnv , PTAL at the new code
There was a problem hiding this comment.
The code is not compiling, let me know when that's fixed 🙏
| /// ``` | ||
| pub fn with_supported_hash_codes( | ||
| mut self, | ||
| codes: impl IntoIterator<Item = multihash::Code>, |
There was a problem hiding this comment.
@lexnv hmm, this way, we would need to add multihash to the sc-network, what about just re-exporting here in this file:
pub use multihash::Code;
or
pub use multihash::Code as MultihashCode;
There was a problem hiding this comment.
pub use multihash::Code as MultihashCode; sounds good to me
| pub(super) cmd_rx: Receiver<BitswapCommand>, | ||
|
|
||
| /// Supported multihash codes for CID validation. | ||
| pub(super) supported_hash_codes: std::collections::HashSet<u64>, |
| /// ``` | ||
| pub fn with_supported_hash_codes( |
There was a problem hiding this comment.
nit: Let's mention we are operating with Blake2b256 by default
| /// Set supported multihash codes for bitswap CID validation. | ||
| /// # Example | ||
| /// | ||
| /// ```rust |
There was a problem hiding this comment.
This will probably compile the example, maybe we want to fix the doc example with some imports behind # so they don't get rendered in docsrs 🙏
| event_tx: config.event_tx, | ||
| supported_hash_codes: config.supported_hash_codes, |
There was a problem hiding this comment.
Nit: let's add a debug in the fn new to know the supported hashes, just in case we start hitting Unsupported multihash code: {code} for cid: {cid}; or add there the full supported list (since it shouldn't be that big)
| if !self.supported_hash_codes.contains(&code) { | ||
| tracing::debug!( | ||
| target: LOG_TARGET, | ||
| "Unsupported multihash code: {code} for cid: {cid}" |
There was a problem hiding this comment.
| "Unsupported multihash code: {code} for cid: {cid}" | |
| code, | |
| cid, | |
| expected = ?self.supported_hash_codes, | |
| "Unsupported multihash" |
| @@ -1 +1,2 @@ | |||
| /target | |||
| .idea | |||
There was a problem hiding this comment.
nit: This is unrelated to the PR
dmitry-markin
left a comment
There was a problem hiding this comment.
IMO we can simplify the PR substantially.
I don't think we should complicate the litep2p Bitswap configuration with a multihash code filter. It would be more straightforward to pass CIDs as is to the client code, that knows anyway what codes/codecs it supports. The client code can then decide whether to respond with a DontHave message straight away, or silently drop such request.
I like this also, so basically, you are saying, we just remove the CID filter from litep2p and we do this filtering in the PolkadotSDK part, right? Is anybody else using litep2p bitswap handler? Just asking, that we allow all CIDs now :) |
@lexnv wdyt? |
That's unlikely, especially because it is not generic (only supports old transaction storage BLAKE2b). In any case, the client code should have the match/check and not rely on the library returning only one magic number. We will also mention this change in the release notes. |
|
@x3c41a ok, so:
then open a new PolkadotSDK PR:
|
|
@x3c41a please change this import: https://github.com/paritytech/litep2p/pull/482/files#diff-944be4d6fcd2bfd09565edd9fffef4d804041dbcb562b25703878eb004cd418aR32 to |
|
@lexnv @dmitry-markin please, check now, can we merge and release? Or what is the release process here? |
+1, I am also curious how the release process look like. |
|
The release process is highlighted in: There's nothing else you guys need to do, we'll handle the release once this PR is merged and bundle with a few other fixes we have in flight. Will let you know when this happens 🙏
We generate the changelogs manually, and prefix the PRs with |
lexnv
left a comment
There was a problem hiding this comment.
LGTM!
The PR title and description would need to change to reflect that we are passing through the CIDs without validation and that users should handle it on their own. (ie, we are no longer adding sha2256 / keccack256 hashing support)
Co-authored-by: Dmitry Markin <dmitry@markin.tech>
|
const blockSizes = chunks.map(c => BigInt(c.length))
let me clean it |
|
Hey @x3c41a, can you setup commit signing with GitHub verified key as per Parity Yubikey guide? We can't merge the PR now because the commits are not signed.
|
|
@x3c41a Note that |
## [0.12.2] - 2025-11-28 This release allows all Bitswap CIDs (v1) to pass regardless of the used hash. It also enhances local address checks in the transport manager. ### Changed - transport-service: Enhance logging with protocol names ([#485](#485)) - bitswap: Reexports for CID ([#486](#486)) - Allow all the Bitswap CIDs (v1) to pass regardless of used hash ([#482](#482)) - transport/manager: Enhance local address checks ([#480](#480)) cc paritytech/polkadot-bulletin-chain#119 --------- Signed-off-by: Alexandru Vasile <alexandru.vasile@parity.io>
Relates to paritytech/litep2p#482 TODO: - [x] bump new litep2p version once it's released --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Branislav Kontur <bkontur@gmail.com>
Relates to paritytech/litep2p#482 TODO: - [x] bump new litep2p version once it's released --------- Co-authored-by: cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Branislav Kontur <bkontur@gmail.com> (cherry picked from commit c5560a2)
Relates to the: paritytech/polkadot-sdk#10301
Fully tested with paritytech/polkadot-bulletin-chain#100
Rationale
The only weak point is that
BitswapRequestHandlerexpects a Blake2b hash (due toBlockT) here: https://github.com/paritytech/polkadot-sdk/blob/e588acf5e12b14c68331d2e08afe7c12d6671df9/substrate/client/network/src/bitswap/mod.rs#L208-L209. However, this is not a real problem, because we initially create a default 32-byte hash and then replace it with the 32-byte hash from the CID. Since we only claim to support 32-byte hashes, it just works. 😊Solution
Proposed by @dmitry-markin - remove CID filtering from litep2p and do filtering in PolkadotSDK - see more.
Follow-up
As a follow-up, I would refactor
fn indexed_transaction/fn has_indexed_transactionhere: https://github.com/paritytech/polkadot-sdk/blob/e588acf5e12b14c68331d2e08afe7c12d6671df9/substrate/client/api/src/client.rs#L154-L163, and make the following change:Ultimately, we index transactions by their content hash, which is a
[u8; 32]here:https://github.com/paritytech/polkadot-sdk/blob/e588acf5e12b14c68331d2e08afe7c12d6671df9/substrate/primitives/io/src/lib.rs#L1494,
and it is generated as a
[u8; 32]here:https://github.com/paritytech/polkadot-sdk/blob/e588acf5e12b14c68331d2e08afe7c12d6671df9/substrate/frame/transaction-storage/src/lib.rs#L239-L242.